Risk-appropriate validation for live operating system migration

ABSTRACT

Methods for migrating a virtual machine instance between devices include scoring a received migration request against one or more rules in a rule database relating to one or more respective validation sets. Each validation set includes one or more validation subtasks. Each score is compared to a respective threshold to determine if a level of risk according to the respective rule merits performing validation. The migration request is validated by one or more validation sets that correspond to the scores that exceed the respective threshold.

BACKGROUND

Technical Field

The present invention relates to migration of operating systems betweenphysical devices and, more particularly, to risk aware validation ofoperating system migration.

Description of the Related Art

Virtual machines allow multiple client operating systems to run on asingle physical device with various input/output (I/O) resources beingvirtualized by a virtual I/O server (VIOS). In addition, a given clientoperating system may be migrated between physical devices, transferringthe client operating system and any workloads to the new device.Migration may be performed while the client is active and running.

These migrations, or “mobility events,” are coordinated by a controlpoint that communicates with the VIOSes on the source device and theVIOSes on the target device. Validation is performed to verify that themigration can be performed safely. During validation, the control pointfirst establishes an inventory of the resources that are available tothe client on the source device. It then confirms that sufficient andcorrect resources are available for the client operating system on thetarget device. If validation succeeds, then the control point initiatesthe migration.

Validation checks can take up a significant portion of the overallmigration time. In addition, validation checks are often redundant,being performed regardless of how unlikely they are to fail.

SUMMARY

A method for migrating a virtual machine instance between devicesincludes scoring a received migration request against one or more rulesin a rule database relating to one or more respective validation setscomprising one or more validation subtasks. Each score is compared to arespective threshold using a processor to determine if a level of riskaccording to the respective rule merits performing validation. Themigration request is validated by one or more validation sets thatcorrespond to the scores that exceed the respective threshold.

These and other features and advantages will become apparent from thefollowing detailed description of illustrative embodiments thereof,which is to be read in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The disclosure will provide details in the following description ofpreferred embodiments with reference to the following figures wherein:

FIG. 1 is diagram of migrating a virtual machine instance in accordancewith the present principles;

FIG. 2 is a block diagram of a migration controller in accordance withthe present principles;

FIG. 3 is a block/flow diagram of a method for migrating a virtualmachine instance in accordance with the present principles; and

FIG. 4 is a block/flow diagram of a method for migrating a virtualmachine instance in accordance with the present principles.

DETAILED DESCRIPTION

Embodiments of the present invention establishes distinct validationtasks that each address specific migration risks. When preparing tomigrate a client operating system or virtual machine instance from afirst device to a second device, factors relating to the source,destination, and broader environment are considered to determine whichrisks most threaten the migration. Appropriate validations are thenperformed to address those likely risks while other validations are notperformed, substantially shortening the validation process.

Validations are therefore grouped into sets. A validation set mayinclude, e.g., storage device access, which verifies that all neededstorage devices are accessible by the destination device with adequatepathing redundancy; storage area network (SAN) bandwidth, which verifiesthat adequate bandwidth is available between the destination device andstorage devices; network bandwidth, which verifies that adequatebandwidth is available between the destination device and importantnetwork peers; workload throughput, which verifies that the destinationdevice can achieve some threshold level for an application benchmark andthat the destination device has adequate processor and memory resources;and tunable sanity, which verifies that the migrating client operatingsystem can boot in the destination virtual machine by, e.g., performinga tentative boot with write protection for the boot device.

In preparation for a migration, a set of applicable risks is determinedand an appropriate set of validations is performed to mitigate thoserisks. Risks may include:

Migration between remote data centers. If a client operating system isbeing migrated between devices in different locations, the destinationwill have different attachments to SAN and internet protocol networks,which implies a risk to accessibility and throughput. In this case,validations should be performed on SAN device access, SAN bandwidth, andnetwork bandwidth.

Migration to a remote device within a data center. If the device is morethan a threshold number of hops away on the local network, then avalidation on network bandwidth is performed.

Migration to a destination virtual machine with a slower processor orsmaller memory size. In this case, validation is performed to verifythat the destination virtual machine will have the computing resourcesneeded to operate the transferred workload.

Migration to a destination virtual machine with fewer storage adapters.In this case, the availability of sufficient storage access is at risk.Validation is therefore performed on SAN device access and SANbandwidth.

Tuning changes to the client operating system. If the migration inquestion is the first migration to be performed on the client operatingsystem since a tuning change was made on the client operating system,validation is performed on the sanity of tuning parameters in the newenvironment.

Adding or removing storage. If the migration in question is the firstmigration since storage was added or removed from the client operatingsystem, then validation on SAN device accessibility is performed.

Referring now to FIG. 1, migration of a client operating system is shownin a data center 100. The first and second devices 102/104 each runrespective virtual input/output servers (VIOSes), also known asvirtualization hosts or hypervisors. The first device 102 has at leastone client virtual machine or client operating system image. One or moreclient operating systems are migrated from a first device 102 to asecond device 104. In migration, the client operating system begins onthe first device 102 and uses the services of the VIOS on that machine,with the intent of migrating the client operating system to the seconddevice 104 without interruption. This migration may be performed over anetwork. Also connected to the network are one or more additionaldevices, such as storage devices 106 connected via an SAN.

The migration is controlled by migration controller 108, which performsany appropriate validations before triggering the migration. As notedabove, the validations being performed may depend on the circumstancesof the particular migration and the risks posed by those circumstances.

Referring now to FIG. 2, a block diagram of the migration controller 108is shown. The migration controller 108 includes a hardware processor202, a memory 204, and a network interface 206. It should be noted thatother components of the migration controller may be implemented assoftware running on the processor 202 or may alternatively beimplemented in hardware as, e.g., an application specific integratedchip or field programmable gate array.

A validation library 208 is stored in memory 204. Rather than using amonolithic set of validation tasks that are performed in everymigration, the migration controller 108 instead uses a validationlibrary that describes validation subtasks and categories as well asassociated checks. The library may be provided by the VIOS vendor andmay be built into the system or may be user or system modifiable.

An example of a substask in the library might be, for example, SANstorage validation. In this example, the subtask includes a set ofsubtasks and procedures as follows:

1. Gather data on source VIOS. For each virtual Fibre Channel adapterassigned to the client, determine:

-   -   a. the SAN fabric to which the virtual adapter is attached;    -   b. the storage target ports visible to the client; and    -   c. for each storage target port, the list of Logical Units        visible to the client.

2. Validate accessibility on the target VIOS. For each virtual FibreChannel adapter on the client:

-   -   a. search for a physical backing adapter on the target that can        attach to the corresponding SAN fabric;    -   b. masquerade as the client to ensure that the same set of        storage target ports are visible; and    -   c. for each storage target port, masquerade as the client to        ensure that the same set of Logical Units are visible.

This procedure is just one example of SAN storage validation and shouldnot be construed as being limiting.

A configuration database 210 stores configuration information needed forthe various validation subtasks. It includes information about therelationships between VIOSes and virtual machines and the locations ofthose machines. The configuration information may be hierarchical, forexample noting first where a particular machine is hosted and nextstoring information about VIOSes stored on that machine. Theconfiguration database 210 may also include information describing whichphysical adapters are assigned to the VIOSes and to which networks orswitches they are attached. Similarly, the configuration database 210stores information about clients, including which VIOS hosts them andwhich VIOS adapters are backing the client's virtual adapters. Otherinformation, including the size of a client's memory, the number andtype of processors assigned, and distance between pairs of components,may also be stored in the configuration database 210. The distancebetween pairs of components may be measured depending on the type ofcomponent, with some distances being measured in geographical distancesand others being measured in logical distances such as a number of hopson a network.

An event database 212 stores information about validation-relevantevents that have occurred on clients. Events can be reported by themigration controller 108 itself, with examples including migration starttimes, migration end times, and validation results; the VIOSes, withexamples including storage reconfigurations; or by the clients, withexamples including tuning changes. Event information may be general,such as noting that a configuration change occurred, or specific, suchas noting that a tunable parameter was set to a specific value.

A rules database 214 stores rules that are used to score risksassociated with a migration. The rules in the rules database 214reference information in the configuration database 210, the eventdatabase 212, and a migration request to determine the risk scoreassociated with the migration request. Scores are categorized similarlyto the subtasks in the validation library 208.

For example, if the latest storage reconfiguration event for a migratingclient is more recent than the latest SAN storage validation for themigrating client, then a SAN storage validation risk may be increased bya set number. If the distance between an Ethernet switch attached to anadapter backing the migrating client and an Ethernet switch attached tothe proposed adapter for the migrating client is greater than a setnumber of hops, then the IP bandwidth risk is increased by a set number.If the requested memory size of the migrating client is smaller than thecurrent memory size of the migrating client, then a transactionthroughput risk may be increased by a set number. The rules database 214may also store rules describing risk thresholds, beyond which avalidation subtask from the validation library 208 is triggered. Forexample, if the SAN storage validation risk is above its respectivethreshold, then SAN storage validation is triggered.

The migration controller 108 receives a migration request from, e.g., asystem operator or an automated management process such as a loadbalancer. The migration request may include various details of themigration, and specifically will include information that isfundamentally needed for the migration (such as identifying the clientto be migrated and the target VIOS or device for the migration). Clientsmay also be reconfigured (e.g., resized, etc.) during a migration, so amigration request may also include information about the desiredend-configuration of the client, including a number of processors toassign, an amount of memory to assign, and a number and type of virtualI/O adapters to attach.

Referring now to FIG. 3, a method of performing a migration is shown.Block 302 receives a migration request to move a client operating systemfrom one device to another. Block 304 scores the migration requestagainst rules in the rule database to determine a risk for each of thetypes of validation that might be needed. Block 306 compares the scoresfor each type of risk against a corresponding threshold. If a scoreexceeds the threshold, block 306 performs the corresponding validationset to ensure that the migration may proceed safely. If block 308determines that one or more validation checks failed, block 310 deniesthe migration request.

Otherwise, block 312 performs, or triggers the performance of, themigration. Block 314 updates the configuration database to reflect thefact that the client operating system is now located on a differentdevice and block 316 updates the event database to include informationregarding the fact that validation and a migration occurred.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Reference in the specification to “one embodiment” or “an embodiment” ofthe present principles, as well as other variations thereof, means thata particular feature, structure, characteristic, and so forth describedin connection with the embodiment is included in at least one embodimentof the present principles. Thus, the appearances of the phrase “in oneembodiment” or “in an embodiment”, as well any other variations,appearing in various places throughout the specification are notnecessarily all referring to the same embodiment.

It is to be appreciated that the use of any of the following “/”,“and/or”, and “at least one of” for example, in the cases of “A/B”, “Aand/or B” and “at least one of A and B”, is intended to encompass theselection of the first listed option (A) only, or the selection of thesecond listed option (B) only, or the selection of both options (A andB). As a further example, in the cases of “A, B, and/or C” and “at leastone of A, B, and C”, such phrasing is intended to encompass theselection of the first listed option (A) only, or the selection of thesecond listed option (B) only, or the selection of the third listedoption (C) only, or the selection of the first and the second listedoptions (A and B) only, or the selection of the first and third listedoptions (A and C) only, or the selection of the second and third listedoptions (B and C) only, or the selection of all three options (A and Band C). This may be extended, as readily apparent by one of ordinaryskill in this and related arts, for as many items listed.

Referring now to FIG. 4, a block/flow diagram of an overview of thepresent principles is provided. Block 402 determines a limited subset ofthe available validation tests to perform based on a particularmigration request, the source system, the target system, and anyappropriate historical information. This may be accomplished asdescribed above, by establishing that there is a low need for certainvalidation tests corresponding to a likelihood that those tests will beunnecessary or redundant. These tests are excluded from the set ofavailable validation tests to form a limited subset of validation teststo be performed. Block 404 then performs the limited subset ofvalidation tests. If the validation tests succeed, block 406 proceedswith the migration.

Having described preferred embodiments of risk-appropriate validationfor live operating system migration (which are intended to beillustrative and not limiting), it is noted that modifications andvariations can be made by persons skilled in the art in light of theabove teachings. It is therefore to be understood that changes may bemade in the particular embodiments disclosed which are within the scopeof the invention as outlined by the appended claims. Having thusdescribed aspects of the invention, with the details and particularityrequired by the patent laws, what is claimed and desired protected byLetters Patent is set forth in the appended claims.

The invention claimed is:
 1. A method for migrating a virtual machineinstance between devices, comprising: scoring a received migrationrequest against one or more rules in a rule database, each rule relatingto one or more respective validation sets comprising one or morevalidation subtasks, to generate one or more scores for the migrationrequest; comparing each score to a respective threshold using aprocessor to determine if a level of risk according to the respectiverule merits performing validation for each respective validation set;validating the migration request by only those validation sets thatcorrespond to the scores that exceed the respective threshold; andmigrating a virtual machine to a target device in accordance with themigration request if none of the validation sets fail to validate themigration request.
 2. The method of claim 1, wherein the validationsubtasks are grouped into sets according to risk type.
 3. The method ofclaim 2, wherein the validation sets include validation subtasks thathandle one or more of storage device access checks, storage area networkbandwidth checks, network bandwidth checks, workload throughput checks,and tunable sanity checks.
 4. The method of claim 1, wherein performingvalidation subtasks comprises referring to a configuration database thatmaintains information regarding the configuration of virtual machineinstances and devices.
 5. The method of claim 1, wherein the one or morerules comprise one or more rules that consider previous events describedin an event database.
 6. The method of claim 5, wherein the previousevents comprise one or more of migration events, virtual machineinstance tuning events, and changes to virtual machine instanceconfiguration change events.
 7. The method of claim 1, wherein each rulehas a corresponding point value and wherein scoring comprises combiningpoint values for violated rules.
 8. The method of claim 1, whereinvalidating comprises omitting one or more validation sets having scoresthat did not exceed the respective threshold.
 9. The method of claim 1,further comprising migrating the virtual machine instance to a targetdevice only if the migration request passes all of the appliedvalidation sets.